「うちのDevOps事情〜大規模サービスのモニタリングあれこれ〜」というイベントで監視と通知の割れ窓について話してきました #mydevops129

#DevOps

塩谷啓

2020.01.30

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

事業開発部の塩谷 (@kwappa) です。

1/29にTECH PLAY SHIBUYAで開催された、「うちのDevOps事情〜大規模サービスのモニタリングあれこれ〜」というイベントに登壇の機会をいただいて話してきました。

まえおき

昨年9月の入社以来、「Team Reliability Engineer」というジョブタイトルをつけて心理的安全性とか礼節とかアジャイル開発についての情報発信や啓蒙を社内外にしてきたのですが、昨年12月から自社サービスであるprismatixの運用 / SREを担当する「Opsチーム」において、マネージャーとスクラムマスターという仕事もしていました。

Opsチームのミッションは多岐にわたります。日々増え続ける運用タスクをこなしつつサービスの信頼性を改善しつづけ、さらにインフラ費用の削減というビジネスインパクトも期待されています。そこに限られた人数で取り組んで疲弊しているチームにモチベーション高く仕事をしてもらうために、運用の周辺業務をあれこれ巻き取ったりタスクの整理をしたり、というロールで参加しています。

もともとキャリアの大半はアプリケーションエンジニアだったので、インフラもクラウドも運用もあまり経験がありません。「スクラムマスターはテックリードでもあれ」という格言（要出典）もあるので迷うところはあったのですが、チームの信頼性を上げるのがミッションならやらざるを得ないだろうと引き受け、それ以来奮闘の日々が続いています。

そんなタイミングで登壇のお声がけがあったのはなにかの巡り合わせだろうと思い、専門外ながらもがんばって喋ってきました。

スライド

内容について

ここしばらくはスライドを見ればだいたい内容が把握できる（うえで実際に聞くとプラスアルファがある）ように心がけているのですが、今回はちょっとフォローが必要そうなので、もう少しおつきあいいただけると幸いです。

割れ窓

ちょっとおもしろおかしく強調して書きましたが、サービス運用ではよく見かける、いいところもあれば悪いところもあるさ、というお話です。プログラミングの領域では「コードスメル」なんて言い方もしますが、スライドに書いた通り「放置されてるなんかあかんやつ」のことです。

Datadog

「ひとつ足したらひとつ消す」というのはちょっと大げさですが、不要なやつは消していきましょうね、という自戒です。通知の数が多すぎるとだんだん気にしなくなっていく、ってのが典型的な通知における割れ窓なので、数を増やさない努力は重要だと思っています。

また、通知は設定したら終わりではなく、閾値などの条件を継続的にチューニングしていくのが異変に早く気づき安眠するコツです。そのためにも数が少ない方がいいのは自明ですよね。

Sentry

このツールは「Devとの対話」の重要性を改めて気づかせてくれるものでした。スタックトレースにビビらず踏み込んで読んでいこう、わからないところはDevと会話し、一緒に警告を減らしていこう。テキストにすると当たり前のことですが、地道に続けていくのはなかなか大変です。

まだツールそのものに対しての練度は不足しているので、引き続きよい使い方を探っていこうと思います。

Pingdom

外形監視をしたいというのはサービス運用する上では当然なのですが、単純にコンテナの生死を監視するだけではあんまり意味がないんじゃないか、という疑問もついて回ります。コンテナは生きててエンドポイントはHealthyを返すかもしれませんが、じゃあサービスはちゃんと稼働しているのかどうかを知ることができなければ、外形監視はあんまり意味があるものとは思えないと言うのが持論です。

こちらもツールの練度を上げてもっと有効な監視にするか、もしくはバッサリやめちゃうか…というのを考えています。